The Programmer Disk

home *** CD-ROM | disk | FTP | other *** search

/ The Programmer Disk / The Programmer Disk (Microforum).iso / xpro / basic1 / pro10 / macro.doc < prev next >

Wrap

Text File | 1989-04-05 | 50.4 KB | 1,189 lines

GLIB Macro-Routines Copyright (C), InfoSoft 1987-1988 GLIB contains and premieres several higher-level routines not available in ANY other library collection whatever the price. These routines do more, much more, than the average call to simply save the screen image or whatever. These are more like complete programs in themselves, yet they remain callable from QB (and in some cases 'C') to perform a a function, or set of functions. For lack of a better term, we are calling this type of callable routine a macro-routine to differentiate them from simple calls or primitives available from most all run-of-the-mill library collections. The term high-level, as used here, is simply meant to indicate that the routine or call is a complete subprogram, not just a sub- routine or function. Many remain in Assembler. The macro-routines currently included, and documented here are: A. FED - A complete input handler for editing input. B. Clock - An installable and accurate time display. C. QCalc - A complete, full featured calculator. D. FlexMenu - All pupose, flexible menuing routine E. StatLine - A set of status line control routines. A. Field Editor - Keyboard Input Handler (C) InfoSoft, 1987, 1988 I. Introduction There are several (indeed many!) text input handlers around. I know, because I have, or have looked at, many of them at one time or another. Many of them require significant editing to work, or they are not modular, or they require the event trapping switch, or they were inadequate in functionality. This is not to imply that FED is without its own failings, but overall, it is very flexible. FED, which originally stood for Field EDitor, is modular. It can be called from the main code of another program very easily. As is, FED is very flexible in most every aspect. You can change most all of the operating parameters with the change of a flag or two. Finally, FED does not require the use of any event trapping switch, it identifies extended key codes on its own, like most any text input routine should. II. FED Files The key FED files are: FED-DEMO.BAS - The demo EMP.DAT - A random file of 7 or so records for the demo The demo is a pretty simple random file allowing you to edit the various records in the file. It is especially easy to use after reviewing this documentation. You are encouraged to read this first so that as FED-DEMO executes, you can notice some of the key features. III. FED Parameters, Syntax FED uses several switches and 3 arguments to control the flow and text input. The formal or direct parameters are: TEXT$ - The text string to edit. FSIZ - An integer telling FED the maximum length allowed for the TEXT$, the current text to be edited. FCODE - The exit code returned by FED to tell you HOW they completed that field or what key was pressed to exit FED. You should understand that you can actually use any names that suit you in a call to a SUB / END SUB subroutine. That is, you could use ED$ instead of TEXT$, or T$, or whatever you want. FED will operate just as expected, as long as you pass them in the right order. The correct syntax: CALL fed(text$, fsiz%, fcode%) The importance of FSIZ is that FED will not allow input after that maximum size is reached, and maybe beep (bleep actually). FED does not change FSIZ on the return, so be sure to reset it for each successive call. IV. Incorporating FED to your code There are a few simple things to do to get FED running in your program: FED works off of 3 formal arguments (covered above) and several COMMON parameters shared with the main, calling program. This allows you to share some parameters with FED very easily such as Foreground Color, upper casing etc. The actual use and meaning of these common parameters are covered later, here we are explaining how to set up for FED to work in your program. This is done by simply including the following line in the beginning of your main code: COMMON /fedvars/ fg%, bg%, fgd%, bgd%, alarm%, edited%, nums%, num$,_ upcase% It is important that you list them EXACTLY as shown, ie in the order shown, WITH the type declarations. The first four are foreground and background colors and the rest are listed alphabetically. Note that such COMMON statements must appear in your code BEFORE any executable statements. If you are not familiar with the use of COMMON it is suggested that you review this in the QB manual(s). Also refer to the FED-DEMO source for proper set up. In implementing the FED variables, we have opted to make several of them COMMON to allow FED to read and literally share the value of these variables with your main program and at the same time, keeps you from having to pass all of them as formal arguments to FED. That is, intead of: CALL fed(t$, fsiz, fcode, fg, bg, fgd, bgd, alarm, edited, nums,num$,_ upcase) all we do is: CALL fed(t$, fsiz, fcode) Additionally, a benefit of this is that the COMMON switches are used or reset MUCH less often in use than say, the text$ would be; for example, most likely, you would set the color switches once (fg, fgd, bg and bgd), but text$ gets changed at almost every call. The only restriction in this is that unlike the formal arguments passed in the parentheses, the COMMON /fedvars/ variables _MUST_ use the variable names shown. That is, while t$ can be changed to text$ or fcode can be used as fed.return.code as you please, fg must be referenced as fg, fgd as fgd, edited as edited, upcase as upcase etc etc. The use of a blockname (/fedvars/) prevents FED from interfering with other COMMON or COMMON SHARED variables, more precisely, it allows the USE of additional COMMON or COMMMON SHARED variables. To name additional variables as COMMON declare them like this: DEFINT a-z COMMON /fedvars/ fg%, bg%, fgd%, bgd%, _ alarm%, editedt%, nums%, num$, upcase% ' FED block COMMON SHARED /newblock/ arg1, arg2, arg3 ' different block COMMON SHARED a,_ ' "blank" block of b,_ ' COMMON variables c,_ z Note that /fedvars/ need not carry the SHARED attribute, but the use of a blockname allows FED to share those variables that it needs and ONLY those, ie a SIZE error is not encountered if you use other COMMON variables. This allows for maximum flexibility. Of the /fedvars/ variables, only edt, a more or less auxiliary flag is altered by FED. V. Internal Editing Keys Internally, FED does several things to provide a professional "look" to its operation. First, lets look at the editing functions and keys recognized: HOME Places cursor at start of text or field. END Places cursor at first blank at end of the text. Ctrl - End Clear line from cursor to end of line. Ctrl - X Clear all text from current field. Ctrl - U Undoes current edit. This does not restore the text to it's form in a disk text file, but restores the text to the form it was UPON ENTRY TO FED. It cannot know what the text was or what form it was in PRIOR to the CALL. Arrow Keys Move one character Right or Left. FED will not allow the user to Cursor right into the hatched area if that means that more than 1 space trails the text. That is, via the the right arrow, it will not allow more than 2 consecutive spaces, as in "J. DOE " or "J Q Public". Multiple spaces can be achieved via the insert key or space however. Ctrl-Arrow Moves one word right or left Keys Tab Moves over 5 spaces without disturbing text. Ins Insert works as expected, allowing text to be inserted at the cursor, and changes the cursor to a block. The Insert state is toggled off upon exiting FED or "finishing" the field or text. Del As expected, deletes characters right of the cursor. No key state flags (such as a [ INS ] or [ Caps ] indicator) are put to the screen. This was viewed as intrusive in that where FED places the flag could be an unacceptable location in some applications, and it seemed to not be in the interest of speed, to be painting and repainting such indicators. VI. FED Return Codes - FCODE This is the half of the meat of the program (The other half is internal). FCODE returns to you a value dependent on what key is pressed to complete the editing of the text. Needless to say, FED has undergone several forms and formats since I first started work on it. The object of most changes has been to make the FCODEs more intuitive. The current state may not seem to be as intuitive as they could be at first glance, but in keeping the dual goals of ease of use AND flexibility, but the actual FCODE handler (the routine called CHGFLD in FED-DEMO) can be "canned", or predone to be incorporated into your program. FCODE Returns: Enter - 0 F1 - 1 F8 - 8 F2 - 2 F9 - 9 F3 - 3 F10 - 10 F4 - 4 PgUp - 11 Up Arrow - 5 PgDn - 12 Dn Arrow - 6 Ctrl-PgUp - 13 F7 - 7 Ctrl-PgDn - 14 Escape - 15 Note that not EVERY possible key is trapped or returned. Most notably, F5 and F6 are not trapped. This is not because FED is lazy or dumb, but simply to cut down on the number of FCODES you need to handle (and handle whether your program uses or needs those codes or not) and to leave 2 keys open for response to any standing ON KEY() key traps your main program may need to have active at all times. I have used FED in hundreds of applications and more often than not, the keys trapped as is, are MORE than enough to do the job. If you look at FED-DEMO you will see that it does quite a bit, in record paging, abort and save keys, and still has 3 or 4 FCODEs unused. In the long run, you should find that FED offers a sufficient number of editing keys and with the use of a pre-done ChangeField routine, it should be easy to handle the number of FCODES that it can return. VII. Internal Handling, COMMON Parameters FED does a few things internally on its own and a few others you control and change throughout the course of your program by resetting the COMMON parameters. If you are not familiar with SHARED parameters you should refer to your QB manual. These are not passed as formal arguments inside the parentheses when the program is CALLed but are set in your main program. Using the value of FSIZ as the maximum length allowed, FED provides hatching from the end of the actual text to that maximum length. If a string is longer than FSIZ upon entry to FED, it is truncated to the maximum length. ( It is important to note that upon GETting a string from a random file, QB pads the string with spaces from the end of the text for the length of the FIELD. That is, if you LSET "JOHN DOE" in a FIELD 15 characters long, after a GET, the name becomes "JOHN DOE ". If you pass this as is to FED with a FSIZ of 15, no hatching will appear because FED does not distinguish the spaces as blank text or attempt to modify the string.) - FED also highlights the current text or data as well as providing the hatching. When the editing is completed, and one of the 15 FCODE keys are hit to exit the field (actually FED is exited, and control is returned to you), the highlighting is turned off. This color control is handled thru the use of 2 sets of color codes: FG, BG and FGD and BGD. These must be assigned valid BASIC color codes in the course of your main code. At the start, FED uses the FGD, BGD (as in ForeGround_Data, BackGround_Data) colors and upon exiting, redisplays it in the FG, BG colors. These only need to be set once. - Caps or uppercase input from the keyboard can be forced on the fly (ie without a separate call) via the UCASE switch. Set UPCASE to 1 or non zero for caps, 0 for to allow either lower or upper case. Note: Previous to GLIB 1.3, this parameter was named 'ucase', starting with GLIB 1.3, this is renamed 'upcase' to avoid conflicting with QB4's statement UCASE$. - Numbers ONLY can be selected in the same manner with the switch NUMS. When this is set, only numeric input is allowed, so to allow for a mixed string such as an address, NUMS should be OFF (nums=0). Additionally, you can redefine allowable characters for different entries via NUM$. For example, in a phone number entry the characters "()-" may be allowable beyond 0-9, but in a dollar based entry $ and "." may be allowable. So prior to the CALL for a phone entry NUM$ would be set to "1234567890()-", or ".1234567890$" for the dollar based entry. This method of defining the entire string rather than just the extra ()-$ or . characters was chosen to allow category type entries also. That is, to force, say a gender selection of M or F, set UPCASE to 1, NUMS to 1 and NUM$ to "MF". If NUM$ is set to null, (num$=""), it defaults to "1234567890". - If the text string upon exiting FED is different than it was at the start of the CALL to fed, then EDITED is set to non-zero. This allows you to test to see if field in a record has been altered. FED only sets it to 1 never to 0. Since FED is just handling the input for different strings, it never knows when a set of fields equalling a full record is completed. EDITED is how FED tells you that something has indeed been edited. ( Using this flag, you can include code in your ChangeField routine to flash a message that an EDIT is in process, as is done in FED-DEMO. It is also useful in precluding certain functions if an edited record is not saved. An example of this is shown in FED-DEMO where paging is disallowed if a record is edited and unsaved. - The final COMMON parameter to cover is ALARM, this is a switch to indicate whether sound is to be on or off. The sound is more of a bleep than a beep. If this switch is set (non zero) it allows the bleep sound effect to sound at various times: - An attempt to cursor right when the string has reached FSIZ (maximum length). - An attempt to enter an invalid character (an alpha character when nums is ON). - When an inserted character will cause the text to exceed the maximum length. - Cursor left attempted left of first character position. - If cursor right appends more than 1 successive blanks to the text. Regardless of the state of bleep, FED disregards any such illegal activities. Alarm just adds an error sound to the process. While the error sound has it's uses, it is not recommended that it be on all the time - there are time when it is inappropriate. In such cases, (such as in an office bullpen setting where such BLEEPING would be annoying), clear the Alram flag (Alarm = 0). In summary, the COMMON switch (0 or 1) parameters are: UPCASE - Convert alpha input to Uppercase NUMS - Allow (numeric) input only from NUM$ NUM$ - Character string filter of allowable input to be used if NUMS is not 0. FGD, BGD - Foreground and Background colors to display the string in while that string is undergoing editing via FED. FG, BG - Colors FED restores the string to upon exiting FED. EDITED - Flag set by FED to show if text is changed. ALARM - Switch to turn on or off BLEEPER error signal. B. CLOCK I. Introduction CLOCK allows your program to provide an ongoing display of the time time WITHOUT the hassle, heartache or overhead of executing GOSUB statements to print TIME$. CLOCK works much the same as a DOS level TSR, that is, it installs itself in memory, latching onto to certain system functions or interrupts to update a display of the current time as needed. The format of the time display is " hh:mm:ss ?m ". The hour display is in 12 hour format, with a trailing am or pm label. The problem with most similar time display programs is that they are not accurate! Over the long haul, a simple time keeping process is most likely to lose about .2 seconds each second. This may sound trivial or insignificant, but in a mere 5 minutes, the time display can be off as much as 2 or 3 seconds!! If your program is to run for hours on end, after a few hours, the time display will simply be inaccurate to a wholly unacceptable degree. To rectify this, CLOCK uses a secondary internal clock to estimate the amount of time lost from 'True' system time and periodically jumps ahead a second to adjust. The CLOCK in GLIB does not loose an entire second until over 8 hours have passed! During that time, CLOCK's time display consistently remained within a constant .5 to 1 second of the actual system time returned by TIME$. In fact, after 12 hours, CLOCK is incredibly still within 1 second! Over extremely long periods, even CLOCK will eventually vary from true time, so for applications that run continually, to adjust the time simply uninstall and immediately re install CLOCK. This will allow it to re-synch with the system time for another 8 to 10 hours. Accuracy is only part of the superiority of CLOCK. The friendly 12 hour-based display with the am/pm label provides a positive, easy to read display and the time display is fully configurable: it can be located or 'popped up' any where on the screen and in any color attribute. CLOCK will also emit a small, pleasant audible tone on the hour and on the half hour even this is configurable. Since CLOCK does take of advantage of TSR-like programming techniques, it is installed rather than simply called, to invoke it. Likewise it must be uninstalled prior to your program termination. It is advised that you fully develop and write your program without CLOCK installed and only when it is fully debugged should you add CLOCK to your code. There is no stand alone time display nearly as accurate as CLOCK. II. Syntax The syntax to implementing CLOCK is very simple: CALL CLOCK(row, col, attr, FUNC) row - The CRT line to display the time display at. col - The CRT column to display it at. attr - The color in attribute form to use in the display. FUNC - CLOCK function to perform: 0 = uninstall clock 1 = normal installation 2 = quiet installation (do not beep at half hour intervals.) Since CLOCK uses TSR type programming techniques, it must be uninstalled when you are done with it. This cannot be understated: CLOCK MUST BE UNINSTALLED BEFORE PROGRAM TERMINATION. This includes program crashes! In the event of a runtime error or crash, CLOCK must be uninstalled before your application exits to DOS. This means if you use ON ERROR type error traps, a call to uninstall CLOCK should be performed. Since CLOCK takes over some very key system interrupts, it is not advised that you use it with other TSR type programs or routines without a THOROUGH checking out of their compatibility. III. Programming Considerations CLOCK cannot be accidentally twice, CLOCK checks for such an attempt and precludes it. Should you wish to change the attributes or location of the display, perform two calls: the first to uninstall CLOCK then another to reinstall it with the new color or location (or both). CLOCK does no internal display preservation, so should you do an uninstall-install routine to change color or location, the last image of the first clock installation will remain unless you restore that portion of the screen or CLS or whatever. C. QCalc I. Introduction QCalc is one of the most powerful and useful callable subroutine in _any_ QB/BASCOM add on package. QCALC has every feature found in a cheap calculator, plus some. QCalc handles values ranging from -2.147 to +2.147 BILLION in either decimal or fixed point (as in dollar values). Such a full featured routine is great in and of itself, but being written entirely in assembler, QCalc takes _under_ 6k in your program and includes an internal screen-save/restore function! QCalc is completely self sufficient: all keyboard, video, bios and math calculations are _internal_ to it. There are no dependencies on other library routines you may or maynot have available to you! Any sort of bookkeeping or number based QB/BASCOM application can benefit greatly from QCalc. QCalc is _not_ a TSR but it does remember the result from the last invocation within the same application! II. Calculator Operation When first invoked, QCalc will draw a representation of a small hand held calculator on the screen, complete with number keys and math operators. This true to life representation makes it ideal for accounting type systems where the user or operator is not necessarily a computer aficionado. QCalc invokes the Num-Lock key for even more convenience, and as numbers are pressed, the presses are replicated on the calculator display. Remember, all this power is available to you and your program with a simple CALL invocation. The default mode is Decimal Fixed Point entry since that is the most likely method for adding sales, calculating tax etc. Math Functions supported: + ... Addition - ... Subtraction * ... Multiplication / ... Division = ... Equals (the Enter key also acts as an implicit equal sign). Numeric Entry: In Fixed Point mode, the decimal can be used to fix the point. That is, entering 1 - 2 - 3 - 4 would result in a display of 1234.00, however, 1 - 2 - . - 3 - 4 would result in 12.34. Commas are not supported as entry characters in decimal mode, however they are displayed as needed. Other Calculator Operations: [Alt -] \ Changes the sign of the entry (like the '+/-' [Alt +] / key on a calculator). Note that these are the _top row_ plus and minus keys, not the grey ones. We would gladly use the grey one also or instead, but the BIOS does not read them when used in combination with the Alt key. As operations are performed, and results displayed, QCalc simulates a physical calculator by retaining a display of the last 5 entries or results, ie a tape. [Esc], [Alt-Q] Abortive type exit - nothing returned [Alt-R] Alt-R, for RETURN, closes the calculator window and returns to your application, returning the last result shown on the calculator. [Alt-E], <E> E or Alt-E is for Clear Entry Clears the number being entered or already entered. [Alt-C], <C> C or Alt-C is Clear All Clears the entry and history by scrolling the tape to clear. [Alt-D] Selects Decimal as the operating base. This is the default when first called. Should you switch to Fixed Point, QCALC will remember and come up in that mode. [Alt-F] Selects Fixed Point as the operating mode. BackSpace The backspace key is fully supported while entering digits. When used on a result, the backspace key acts as the Clear Entry key. Just as in a physical calculator, a result can be rolled over into an entry. Example: 4 * ; an entry 4 = ; 4*4 = ?? 16= ; 16 is a _result_ + ; tapping plus turns 16 into an _entry_ ! 16+ III Operation Tips QCalc can do any addition, multiplication, division or subtraction as long as the result and both operands are within the +/- 2.147 BILLION range. Overflowing or underflowing this range will cause numbers to wrap: ie 2.147 BILLION plus 1 = - 2.147 BILLION and vice-versa. Percentages, as in a tax calculation, are easily handled with multiplication or division: Method 1 ( 2 step process): Tax rate of 5% on 34.65 34.65 * ; result of addition etc turned into entry .05 ; enter as "." - "0" - "5" = ; hit enter or equal 1.72 ; this is the 5% tax amount (a _result_ !) + ; turn result into entry 34.65 = ; add back in the taxable amount 36.37 ; Total amount due Note: For various reasons, the 5% amount, which is actually 1.728 is returned as 1.72 not rounded to 1.73. Method 2 (1 step process): 34.65 * ; result of addition etc turned into entry 1.05 ; enter as "1" - "." - "0" - "5" = ; hit enter or equal 36.38 ; this is the 5% tax amount (a _result_ !) Note: This is not only simpler and faster, it is more accurate! However many people do not understand that the total amount is going to be 100% of the taxable amount _plus_ 5%, ie 105% or (n * 1.05). To be able to isolate the tax amount, as might be needed on an itemized bill, just roll over the result into an entry and subtract the subtotal. Continuing from above, this is done like this: - ; roll result into a entry 34.64 ; deduct the subtotal 1.73 = ; the amount added to subtotal ie the tax. IV Syntax and Programming Considerations A. QuickBASIC Syntax The immense power and functionality of QCalc is invoked with a mere 5 parameters that control virtually everything: Syntax: DECALRE FUNCTION QCalc&(Row%, Col%, Body%, Scrn%, Button%, SpeedMode%) .. .. .. RetVal& = Calc(Row, Col, Body, Scrn, Button, SpeedMode) B. Turbo-C Version extern long near qcalc(int row, int col, int body, int scrn, int msg); .. .. .. long retval = 0; retval = qcalc(row, col, a, b, c); printf("%ld",retval); For the large memory model, simply substitute 'far' for 'near' in the declaration. C. Parameters: RetVal& - QCalc will return to you the last _result_ value on the QCalc display. An entry value will not be returned. That is, entering '1+1=' will return 2. Simply entering 1 only, with no operation, will return the result of the last operation. This _must_ be a long integer. See the warning below. Row, Col - Denotes the upper left row, col coordinates for the calculator display. The size of the calculator display is 31 characters wide, 20 columns tall - roughly 1/3rd of the screen. QCalc is not only functional but it is very smart too: should you pass invalid coordinates for the row/col, it will adjust them so that the calculator display does not wrap. Three attribute values are passed to customize the calculator display to specifically your needs. QCalc will use the correct display mode for mono vs color/ega/vga displays, but does no second guessing on the attributes you pass. Be sure that the attributes you choose are appropriate for the display present. EGA's must be in 25 row mode or QCalc simply exits gracefully. Body - The color to use in the calculator body. This is the predominant color used. Screen - The color to use on the 5 line calculator display. Since the end user will be focusing on this, it should be an easy to read color, however certain attributes can replicate a LCD appearance to make the display even more realistic. Button - This color is used a very little, only to simulate button presses and the like. Since it is used on the calculator body, some very interesting effects can be created using totally different background colors or the same so that just the key text changes. SpeedMode - This allows the programmer or end user to tailor a portion of the operation characteristics. When a numeric key (0-9), E or C is pressed, the appropriate display is briefly recolored with the Button Color and a tone sounds. The SpeedMode parameter allows you to set the duration for the tone in clock ticks (1 / 18.2 seconds (we suggest 2). This time is not system dependant so it makes no difference is QCALC is called on a 386 or a 8088 machine. However, you may want to turn off the beep tone or speed it up or slow it down the SpeedMode parameter affords you this option. Additionally, after the beep, QCALC purges the keyboard buffer of type ahead characters, which is also disabled with the SpeedMode parameter. SpeedModes 0 to 4 do not purge the type ahead buffer and represent in clock ticks, how long the tone should sound in the beep/button recolor operation. Zero is the shortest, with the beep/recolor disabled, four is the longest with it taking about 1/2 second (twice as long as a BASIC or DOS Error BEEP !). For reference, we recommend 2. SpeedModes 5 to 9 represent the same clock tick count as 0 to 4, that is, SpeedMode 5 disables the beep with the difference being that SpeedMode 5 to 9 DO purge the type ahead buffer. So SpeedMode 7 provides the same display effect as 2 with the difference being that 7 will eat up any keys waiting in the keyboard buffer. V. Programming Considerations QCalc returns the last _result_ on the display to your program. This means that in a book work type program, you could pop up QCalc to allow the user to add up sales or paid outs, and when they leave QCalc via [Alt-R], QCalc will return the last result shown on the calculator display! Your program could then automagically insert that value on the screen and the proper variable! If the user leaves QCalc via [Esc] or [Alt-Q], QCalc simply 'pops down' and does not attempt to return anything. You can force a return to your program by simply setting up a loop until QCalc DOES return a value. This maybe helpful in cases where the calculator covers up some of the entry items on the screen forcing the user to occasionally 'pop down' to read more info. Ex: DO UNTIL RetVal& <> 0 RetVal& = QCalc(row, col, attrs, attrb, attrf, speed) IF RetVal& = 0 ' no return LOCATE 23, 10 PRINT "Return Required - Press any key for calculator." ELSE EXIT DO ' return was okay get outta LOOP END IF x$=INPUT$(1) ' get a key, any key LOCATE 23,10 ' cover over msg PRINT SPACE$(46) LOOP NOTE! NOTE! NOTE! QCalc returns a _LONG_ integer. These are 32 bits and requires that your receiving variable must be an _LONG_integer. Attempting to assign the result to an integer _will_ result in OVERFLOW. The return is in decimal mode. If your application is using fixed point numerics, simply divide the return by 100. This means for 'C' you must use the size identifer 'l' in the printf statement of garbage will result of the result returned is larger than 32k. Example: printf("%ld",retval); Notes Within the same program (ie without CHAINing, RUNning or spawning a new module), QCalc retains the display of the last entry or result. Theoretically, this allows the user to pop up QCalc, add up some numbers, pop down to get more info from the screen and return to right where they were - previously entered data is _not_ lost! It is also important to note that second and third and fourth calls to QCalc do _not_ have to be at the same location for QCalc to pop up the same display! QCalc is so incredibly intuitive that if on a second call, it sees that you have altered the screen color it will not restore the screen image, but will redraw the screen with the new colors. This prevents the calculator screen from changing colors as it scrolls, the tape display is lost, but the last result is _still_ preserved! So, while subsequent calls need not be to the same screen location, they should be with the same screen colours. QCalc automagically engages the Num Lock key when invoked and retores it when exiting. Since we are not afflicted with one of the 'enhanced' 10x key keyboards, we are not yet sure what this does with them. However it is in deference to them and their nonspatial-kinesthetic layout that no function keys are used. We hope you enjoy QCalc and find it's vast power and incredible ease of use to be of benefit in your program. We are currently attempting to port it to 'C' language so that should you learn 'C' or are already somewhat multi lingual, this invaluable tool can 'go with you' and your programming endeavors. QuickBASIC 3.0 users note: 1) Get on the ball and get QB4. 2) QCalc will work perfectly as a called sub rather than a Function, however, you will _not_ get the calculator result returned. This means, the user will need to calculate a list of entries or figures, write down or remember the result, then manually re-enter it into the program - hardly ideal. Quick C 1) QCalc was briefly tested with the MS Quick C compiler, and found to work ok. There may be certain peculiarities with Quick C that I am unaware of, but I am not a fan of QC and do not wish to spend any more time with it than I need to. D. FlexMenu Flexmenu is a snappy, full featured, multi purpose menu-select subprogram that supports a plethora of features with a minimum of setup or parameters to manage. Many of the programs we write require easy to use and intuitive menus for novices, yet navigation still needs to be flexible enough so as not to frustrate experts. We routinely use FlexMenu in these situations because it fits all these needs and more. Syntax: item = MenuChoice% (Menu$(), Trow%, LCol%, Nattr%, Hattr%, title$,_ Mark%(), XtdChc%) Using the list of items in menu$(), Flexmenu displays a box on the screen at the location specified by TRow, LCol. FlexMenu automagically calculates the rest of the coordinates (length and width). If the number of choices is greater than 14, the box is truncated to hold the first 14, with the rest being displayed thru the use of the arrow keys. When this is the case, and selections are off the screen either above or below, up and/or down arrows (ASCII 24 and 25) will be located on the right border. The list of choices or menu items is in the color attribute specified by Nattr (Normal ATTRibute), and the current selection is highlighted in color HAttr. An optional title is centered across the top of the box. FlexMenu will elegantly handle as many choices as you can fit into string space. As we mentioned, for appearances, the box is never larger than 14 selections. Navigation is intuitively managed with the arrow keys (Up and Down), Pg Up, Pg Dn, Home and End - all doing what you would expect. Additionally, FlexMenu responds to a alpha search - press "A" will locate and go to (but not select) the first item after our current item starting with "A" or "a". Pressing [Enter] returns to your code the index number of the item pressed. If we are on item 1527, 'item' will be set to 1527. We would find FlexMenu highly useful if that was all it did but it does much, MUCH more: First, it can automatically center the display (which we use almost exclusively) by setting both TRow and LCol to -1. This prevents you from having to twiddle and map out where the center is. Next, it responds to extended keystrokes. If we highlight item 156, and press enter, item is set to 156. If we press [Alt-Q] instead, item is still set to 156, but the extended choice parameter (XtdChc) is set to 16 (the ASCII code for Alt-Q). This allows us to manage multiple functions from one menu. For example, we might use DIR to load a string array and FlexMenu to display the file names and from that, [Alt-D] might delete the chosen file, but [Alt-L] might list it. Then via a SELECT CASE statement the desired functions can be swiftly carried out. To filter out unwanted extended choices, simply place the call to FlexMenu in a DO or WHILE loop: done = 0 DO item = MenuChoice=(Menu$(), -1, -1, 78, 3, "Demo", Mark(), XtdChc) SELECT CASE XtdChc CASE 1, 2, 3, 4 GOSUB MoreChoices CASE 12, 14, 15 GOSUB SomeStuff CASE 16 GOSUB KillFile CASE 23 ' get another selection CLS item = MenuChoice(FList$(), -1, -1, 78, 3, "Demo", Mark(), XtdChc) IF (XtdCHC <> 27) AND (Item > 0 ) THEN GOSUB GoodStuff END IF CLS ' clear for next loop CASE 27 ' Escape done = 1 SYSTEM CASE 18 ' Alt - Q done = 1 CASE ELSE 'unsupported functions END SELECT LOOP UNTIL done In this type of construction, we limit the methods of ending the program to the 2 we are prepared to handle. In this way, the display (menu$() ) can represent either a lift of things to act upon such as file names or a list of actions or a menu itself! Creativity in nesting allows virtually unlimited possibilities -- we have one program that manages some 40,000 items and menu functions in 5 FlexMenu calls. The novice user is always interacting with FlexMenu, never DOS or the engine of the program. There is even more! Flexmenu optionally supports a "Mark Mode" or multiple select function. By setting XtdChc to non zero upon entry, you enable mark mode where pressing the TAB, asterisk or SPACEBAR toggles a mark for that item. The number of marks allowed is set by XtdChc, setting it to 10 allows 10 - and only 10 - items to be marked, set to 5, only 5 would be allowed and so forth. Marked items are tagged with bracketing "»" and "«" (ASCII 174 and 175) characters (only on the display! FlexMenu will not alter your menu array!), and all the other features remain in effect - alpha search, navigation and Extended keyboard selection. To accomplish this, you must pass an array that is of the same size as your main selection string array. FlexMenu will use this as a set of pointers indicating which items are Marked: if elements 5, 6, 10 and 37 are set (non zero) upon exiting, then the user selected or marked selections 5,6, 10 and 37 from the menu. Item will STILL return as the highlighted or current item when ENTER or an extended key is pressed - it is up to you to use it or not. If the Mark integer array is not the same size as the string array of choices, item is set to -1 and FlexMenu aborts. However, if mark mode is NOT desired, enter FlexMenu with XtdChc set to 0 and dimension Mark() to a single dimension. FlexMenu will also "remember" previous marks upon subsequent calls unless you REDIM the MARK array. FlexMenu examines Mark() as it is setting up and treats non zero elements as marks. That is, upon initializing it does not assume that it is the first time. Using this, you can "suggest" selections by setting the corresponding Mark() element before calling FlexMenu - the user can of course toggle it off, but in cyclical applications, the user need not remark previous selections. We use FlexMenu almost exclusively in our menu driven applications, since it is powerful, fast, relatively small and has so many features and have found it to meet most every need. If there is any interest, we could be persuaded into developing a version that uses a Fixed Length String Arrays or one that supports rodents. NOTE: FlexMenu requires the QPrint, Scroll, Painter and Boxes object modules. NOTE ALSO: FlexMenu is the name we have given the module or routine, but it is invoked as MenuChoice. The term "MenuChoice" looks better in the code, but "FlexMenu" is much more descriptive of the routine when describing it in documentation. E. StatLine I. Overview StaLine is the name of the object file containing several routines or primitives that aid you in displaying and/or controlling a one or two row status line. These routines are: CLX - Clear the screen except for the status line area. SetBline - Set the bottom line of the non status line area of the screen. Similar in function to the BASIC WINDOW statment. PrintStatL - Prints all or part of an array designated for the status line. II. Operation The default bottom line of a screen using StatLine procedures is row 23, or a 2 row status line as used in the demo. You can set this to more or less depending on your needs, thus allowing you to use even 5 lines for the status area or even simulating a split screen effect. If you use more than 1 or 2 rows for the status line however, you will need to maintain those above 24 as PrintStatL will only print to lines 24 and/or 25). Beyond that limitation, these routines allow for printing and updating a status line, and clearing the non status line portion of the screen. III. Functions Name: SetBVLine Type: SUB Level: ASM Syntax: CALL SetBVLine(x) As mentioned, the default bottom line of a screen using StatLine procedures is row 23, or a 2 row status line as used in the demo. If you with to reserve more or less area than that, SetBVLine will allow you to Set the Bottom Video Line to be respected by PrintStatL and CLX. Note that if you set it to 23, a call to CLX will ONLY clear lines 1 to 23, saving the bottom two status lines and preventing you from having to redraw them. However, CLS will still clear the entire screen. Name: CLX Type: SUB Level: ASM Syntax: CALL CLX This may also be called or invoked as ClrScrn This simply clears the non status line portion of the screen. Where CLS would clear all 25 rows of video, CLX respects the default bottom video line of 22 or whatever you have set it to using SetBVLine. As with CLS, this will clear the screen, and locate both the PHYSICAL cursor position to 1,1 and reset the BASIC cursor location variables to 1,1 also! No need to LOCATE 1,1 after a CLX simply to let QB know that we cleared the screen. Name: PrintStatL Type: SUB Level: ASM Syntax: CALL PrintStatL(StatMsg(1), Action, Attr) This may also be invoked as PrtSL This prints all or part of a 2 element fixed length 80 character string array to the status line area of the screen in the designted color. 1. To pass a fixed length string array to a CALLed ASM sub, you must hide it in a TYPE structure by setting up a user defined TYPE that is simply a single 80 character string. Ex: TYPE struct ' tell QB what it looks like fls AS STRING * 80 END TYPE DIM StatMsg(2) AS struct ' order one 2. Also to pass a TYPE structure to an ASM routine, you must DECLARE it using the keyword ANY. So the DECALRE for PrtSL would be: DECALRE SUB PrtSL(MsgArry AS ANY, Action%, Attr%) 3. At this point, we may fill the array with messages. Feel free to use LSET or RSET with the array to justify strings. Ex: StatMsg(1).fls = " Time: " + TIME$ + " Temp: "+ degree$ + msg$ StatMsg(2).fls = " Code: " + Information$ 4. Finally invoke it with the desired action code and attribute: CALL PrtSL(StatMsg(1), 0, Attr) Action codes tell PrtSl what action to perform: 0 = Print/Update both lines 24 and 25 1 = Print/update line 24 only 2 = Print/update line 25 only In more sophisticated applications, you can define more than 2 elements for the message array and selectively update higher offsets in the array. For instance, if your program has 5 main function levels, you might need 5 different status line displays. Using a 2 line display means we need 10 elements so, DIM StatMsg(10) AS struct ' set up 5 status line SETS When we are working on the Main or top level we invoke elements 1 and 2 to print to lines 24 and 25 as normal (above). For subsequent levels we pass the element to be mapped or printed to line 24, the second activity level would be: CALL PrtSL(StatMsg(3), 0, Attr) ' element 3 goes to 24, 4 to line 25 ' level 3: CALL PrtSL(StatMsg(5), 0, Attr) and so on to level 5: CALL PrtSL(StatMsg(9), 0, Attr) Of course, your use of OPTION BASE 0 means you subtract one from the element passed. Notes: Being a fixed length string, a very large number of status line messages can be stored in your fixed length sting array, but be sure to use the /ah switch if the arry is to be more than 64k QB inititializes a fixed length string to NULLs, NOT SPACES, so displaying a messgae arry that you have not added text to, may result in unexpected results. PrntSL expects a 2 line status area, so to use only line 25, your message array would still have to be 2 elements per "level", but every other one would be blank or NULL. MsgArry(1) always maps to line 24, as does 3, 5, 7, 9 etc. These would be blank, but 2, 4, 6, 8 etc would be filled for mapping to line 25 when you want to use only line 25. SetBVLine has no effect on PrtSL only on CLX. PrtSL expects the message arry to print to be a 80 character sting array - if you dimension it to a smaller number the memory contents immediately following the arry will be printed. Ex: if you DIM it to STRING * 60 (rather than 80), line 24 would display the first element PLUS the first 20 characters of the second, and the bottom line would display the next 40 characters of the second element PLUS what ever garbage is in the next 40 bytes of memory.